Field
Embodiments of the invention generally relate to techniques to validate a certificate chain. More specifically, embodiments presented herein provide techniques to validate a certificate chain for both pubic and internal server systems that use digital certificates to establish secure communication sessions with clients.
Description of the Related Art
Providing secure communication and protecting sensitive data is a well-known issue in a broad variety of contexts. For example, it is common for computer servers to use digital certificates to associate a server with a network domain. In such cases, clients use information contained in a certificate to verify the identity of a server and to establish a secure communication session with that server (e.g., an SSL or TLS session). More generally, digital certificates and public key infrastructure (PKI) techniques are used to create, distribute, and manage cryptographic keys used in a variety of contexts.
Typically, part of establishing a secure communication session with a server includes verifying that a certificate presented by the server is digitally signed by a “trusted” certificate authority. More specifically, digital certificates include a subject field that identifies the individual or server to which the certificate was issued (i.e., the entity associated with the public key listed the digital certificate). Digital certificates also include an issuer field identifying the certification authority (CA) certifying the identity of the subject. When a server presents a digital certificate, the client can verify whether the issuing CA signing that certificate is “trusted.” The process of verifying the authenticity and validity of a newly received certificate involves checking all of the certificates in a chain of certificates from the certificate presented by a server, through any intermediate CAs, until reaching a certificate issued and signed by CA trusted by the client. A certificate presented to a client is trusted only if each certificate in that certificate's chain is properly issued and valid.
If the server does not present all of the certificates in the chain (along with the end-entity certificate), the client may be unable to verify the chain to a trusted root. Even if all the certificates in the chain are presented, if any of the certificates are no longer valid (or revoked) or if the chain does not reach a “trusted root,” then the client may decline to establish a secure session with the server (or at least present a warning to a user).
Given the possibility for poor user experience with misconfigured or missing certificate chains, tools are available that allow an administrator configuring a server to validate a certificate chain presented by that server. However, to do so, the server needs to be reachable by a validation service. This presents a problem for servers that are visible only on private networks (e.g., only from within an enterprise network) as well as for servers that, while public facing, are behind a load balancer or firewall. For example, consider a web-site operator that deploys a pool of servers in a data center to host a website and that a load balancer distributes requests from clients to servers in the pool. In such a case, it would be preferable for the operator to validate that the certificate chain on each web server in the pool is configured correctly. However, because the servers in the pool are not directly visible to an external validation tool (despite providing a public-facing service), such a validation tool cannot verify the certificate chain for these servers.